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INTRODUCTION 


Mars has always interested the human imagination, like no other 
planet. For ages, humans have been speculating about life on Mars. 
But, the question still unanswered is whether Mars has a biosphere 
or ever had an environment in which life could have evolved and 
been sustained. 

The Mars Orbiter [1], [2], is a space probe launched on 5 No- 
vember 2013 by the Indian Space Research Organization (ISRO) 
[3]. It is ISRO’s first interplanetary mission to planet Mars with 
an orbiter craft designed to orbit Mars in an elliptical orbit, which 
has been orbiting Mars since the 24 of September, 2014. With this 
mission, ISRO has become the fourth space agency to reach Mars, 
after the Soviet space program, National Aeronautics and Space 
Administration , and European Space Agency. 

The Mars Orbiter Mission (MOM) has many technical chal- 
lenges considering the critical mission operations and the stringent 
requirements on propulsion and other bus systems of the space- 
craft. It has been configured to carry out limited study of the Mar- 
tian atmosphere with five payloads [4] finalized by the Advisory 
Committee on Space Sciences. Figure | shows the basic structure 
of Mars Orbiter spacecraft. 

In interplanetary missions where the communication delays are 
quite high, it takes a significant amount of time to send commands 
and receive the telemetry. Also, interplanetary missions involve 
visibility constraints. The round trip delay for a signal in MOM is 
up to 40 minutes. MOM involves a communication blackout pe- 
riod when the Sun is between the Earth and the Mars. Also, there 
exist communication white-out periods when the Earth is between 
the Sun and Mars. Finally, the MOM involves visibility gaps when 
the spacecraft goes behind Mars. Also, the interplanetary mission 
involves different phases of mission operations during its life, so 
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it requires flexibility and programmability to manage the mission. 
Due to visibility constraints and the time delays involved in the 
mission, autonomy features are developed in the telecommand 
processor (MTcP) software, which reduces command uplinks and 
increases the reuse of already uplinked commands. 

In this article, the design and development of the MTcP soft- 
ware for the MOM is presented. MTcP software provides auton- 
omy features for thermal management, fault detection, isolation, 
and reconfiguration (FDIR), differential time tagged (TT) com- 
mand execution, configurable command block (CCB) execution, 
event based commanding (EBC), on board time tagged (OBT) 
command execution, macro time tagged command execution, at- 
titude and orbit control electronics (AOCE) autonomy, 1553B 
[5]-[7] data/command transfer and telemetry transfer to AOCE, 
and other subsystems. The software also has features like te- 
lemetry (TM) auto-changeover, MTcP auto-changeover, remote 
programming, telecommand (TC) history transfer to baseband 
data handling (BDH), and controlled MTcP reset (protection 
from spurious resets). All these functionalities are elaborated 
in the subsequent sections. In the MTcP software, some of the 
functionalities can be combined and used as it provides linking 
feature. The software is successfully flown in MOM [8], [9]. 
The picture of Mars Orbiter Spacecraft mounted on a payload 
adapter in a polar satellite launch vehicle (PSLV) C-25 is shown 
in Figure 2. 
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Figure 1. 


Mars Orbiter Spacecraft basic structure. 
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Figure 2. 
Mars Orbiter Spacecraft mounted on PSLV C25. 
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Figure 3. 


Telecommand system configuration. 
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Commands to Subsystems 


Redundant 


TC HARDWARE DESCRIPTION 


The TC subsystem configuration 
is shown in Figure 3. The TC sub- 
system is interfaced with S-band 
receiver. Digital signals from a 
Phase Shift Keying demodulator 
[10] are fed to the decoders. The 
TC subsystem consists of a Con- 
sultative Committee for Space 
Data Systems standard decoder 
[11], [12], a processor glue logic, 
a command distribution unit, a 
MAR31750 microprocessor [13], 
a memory management unit [14], 
and a 1553B remote terminal [15]. 

There is a provision for cross 
strapping of receivers with decoders. The main and redundant 
MTcPs are interfaced with main and redundant decoders. Due to 
cross strapping of receivers with decoders, commands can be sent to 
decoder 2 from receiver | and also decoder | can receive commands 
from receiver 2. Apart from that, decoder 1 can send commands to 
MTcP 2 and also MTcP 1 can receive commands from decoder 2. 
There exists a provision to send commands to both the processors 
simultaneously through any one of the decoders. The simultaneous 
commanding helps in keeping configuration of both the processors 
the same. The simultaneous commanding is mainly used in MOM. 

The system has a 1553B bus for command/data transfer to 
AOCE and other subsystems. The AOCE package has the bus con- 
troller (BC) for the 1553B bus. The TC provides a remote terminal 
(RT) interface for AOCE 1553B bus. 

The MTcP reads data from the TC decoder and stores, process- 
es, or distributes the command per the pre-defined MTcP modes. 
The picture of TC flight core card designed for MOM is shown in 
Figure 4. 


SOFTWARE HARDWARE INTERFACE 


The hardware-software interaction is through memory mapped In- 
put Outputs [16]. The hardware provides timing reference, telem- 
etry information, and system status for software. 
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Figure 4. 


Telecommand core card. 


The Watch Dog Timer is implemented in hardware, which 
resets the processor periodically if the software failed to reset it 
within a particular period. The software also gets system identi- 
fication (ID) to distinguish between main and redundant systems. 
Therefore, the software is the same in the main and redundant sys- 
tems but configures itself differently by seeing the system ID. 


MIcP SOFTWARE ARCHITECTURE 


The on-board software execution is under the control of a Real 
Time Executive (RTE). The RTE is an infinite loop repeated every 


major cycle comprising of four minor cycles. The RTE executes 
the MTcP software functionalities in round robin fashion in the 
RTE cycle. The MTcP software architecture is general purpose, 
flexible, and robust. A modified water fall model [17], [18] shown 
in Figure 5 is used for the development of MTcP software. 
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Figure 5. 
Modified waterfall model for MTcP software design. 
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Figure 6. 
RTE for MTcP software. 


The modified waterfall model is used to maintain the design 
configuration of the component developments. Each phase has 
a specific deliverable and a review process. It serves to robustly 
check operations to validate software changes still resulting in 
maintained or improved operations. 

The MTcP software consists of a power-on initialization routine 
and a major cycle loop, which runs infinitely. The major cycle loop 
consists of four minor cycles. Various MTcP functionalities are time 
sliced/shared within these four minor cycles. The software architec- 
ture is shown in Figure 6. Clock driven cyclic scheduling [19] is 
used with minor cycle time of 16 ms. The minor cycle time is chosen 
based on software performance under a full load test. Four minor cy- 
cles are used as it is sufficient for all the tasks to complete and, also, 
the generation of the timing reference is easy as it is a power of two. 

The various tasks scheduled in different minor cycles are as 
shown in Table 1. All the tasks within a minor cycle must not take 
more than 75% of the maximum allotted time according to ISRO 
Quality Assurance (QA) guidelines. The minor cycle time is opti- 
mized to reduce context switches and to satisfy the time deadlines 
for various functionalities. For example, telemetry frame rate puts 
a constraint on processing telemetry data within a frame time. EBC 
may have conditions programmed to check data from a same te- 
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Table 1. 
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lemetry frame. Therefore, the EBC sampling logic must check all 
conditions within a telemetry frame time. 

The timing management module maintains time for functional- 
ities like TT, OBT, EBCs, etc. It periodically checks for TM health 
and initiates TM auto-changeover if necessary. The command ex- 
ecution logic decides the priority of command execution. It also 
handles execution of commands from various functionalities. 


MIcP SOFTWARE FUNCTIONS 


The MTcP software design is mainly focused on autonomy require- 
ments and flexibility to meet mission requirements during various 
phases of MOM. Features like TM and MTcP auto-changeover makes 
it more robust. The software features minimize the ground control 
intervention in case of any failure as the mission involves significant 
delays in getting onboard telemetry, as well as visibility constraints. 

Features of MTcP software design are explained below. The 
features are divided as a) EBCs, b) TT Commands, c) FDIR, and 
d) other features. 


EVENT BASED COMMANDING 


lelemetry Event Based Commanding 


While operating the spacecraft, a general requirement is that when 
a particular parameter of a subsystem crosses some limit, or if a 
particular status is set or reset, some specific operation shall be car- 
ried out. To meet this requirement, the software monitors onboard 
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telemetry data of the subsystem/sensors and issues commands cor- 
responding to that event. The software includes a set of arithmetic 
and logical checks (e.g., lesser, greater, all bits high, all bits low, 
etc.) for the telemetry data. Both event condition and commands 
are programmable from the ground. The sampling rate of the data 
is also programmable. A simplified block diagram for telemetry 
event based commanding logic is shown in Figure 7. 

The consistency of telemetry data is monitored and validated to 
avoid spurious event triggering. Multiple event conditions can also 
be combined for a particular action. 

The EBC feature is a general purpose feature and can be effec- 
tively used for normal operations as well as contingency manage- 
ment onboard. 

For example, an event can be programmed to switch off the 
payloads when the battery voltage falls below a particular value. 
EBCs are also used for battery management in spacecraft. In case 
of attitude loss, EBCs are used to detect Radio Frequency bit lock 
and sun presence by rotating the spacecraft. 

The same events can be programmed with different conditions 
and different actions during various phases of the mission. All of 
the events are provided with individual enable/disable control. The 
EBC logic is designed to work at all the telemetry data rates. 


AQCE Events Autonomy Functions 


The AOCE autonomy logic resides in MTcP software. AOCE 
sends events to MTcP and MTcP takes the action by executing 
commands corresponding to that event. The AOCE autonomy 
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Figure 7. 
Telemetry EBC logic block diagram. 


commands are differential time tagged commands. Both event and 
action are programmable. 

For example, if one of the star sensors in the loop goes bad, then 
the event is generated by AOCE to utilize the redundant star sensor 
in the loop. Therefore, if MTcP gets this particular event, then it exe- 
cutes the commands to bring the redundant star sensor into operation. 


Programmable Automatic Thermal Control 


Thermal management plays an important role in proper function- 
ing of the subsystems. The subsystems generally have a require- 
ment to maintain the temperature within certain limits. 

The software continuously monitors the temperature for all of 
the subsystems onboard the spacecraft and operates the heaters to 
maintain spacecraft temperature within certain temperature limits. 
The temperature limits and sensor information are programmable. 

The saturation check logic is also incorporated to take care of 
the any sensor failure. The programmable automatic thermal con- 
trol (PATC) logic has an enable/disable feature. Also, each heater 
has an enable/disable feature. 


TIME-TAGGED COMMANDING 


Differential Time Tagged Command Execution 


The differential TT commands belong to the class of time tagged 
commands. The TT commands are useful when a particular se- 
quence of action and delay is required between the commands. 
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Each TT command has a differential delay associated with it. 
Both command and delay are programmable from the ground station. 

The TT command execution is shown in Figure 8. When the TT 
execution start is given, a certain number (N) of commands are ex- 
ecuted one by one according to differential delays associated with 
them. The TT execution start consists of start command number 
and number of commands to be executed. 


Snap Logic 


The snap signal gets generated when the spacecraft gets separated 
from the launch vehicle. After the snap signal is detected, some pre- 
defined operations have to be done. These operations are loaded in the 
TT stack at the launch pad. The trigger to these commands is through 
the snap signal. The snap logic handles the snap signal and takes the 
proper action after the spacecraft is separated from the launch vehicle. 

For example, a snap sequence consists of actions like solar 
panel deployment, thruster selection, etc. When the spacecraft gets 
separated from launch vehicle, the snap sequence is loaded as TT 
commands get activated. 


Macro 


Macro is a block of differential TT commands which can run in 
parallel independently. The commands and delays are program- 
mable. The Macro TT is slightly different from the conventional 
differential TT as it has two level controls. The Macro TT becomes 
active when it is enabled and initiated. 
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Figure 8. 


Differential TT command execution. 


The two level control is an extremely useful feature in design 
and planning of autonomy. For example, in case of Travelling 
Wave Tube Amplifier (TWTA) autonomy, if the TWTA needs to 
be switched on at a particular OBT but only when the battery volt- 
age is above a particular value, then the OBT event can enable a 
Macro TT and an EBC (checking for battery voltage) can initiate it. 

Also, the macros are useful for payload operations. The Mars 
color camera has been operated by OBT commands triggering 
macros to take pictures of the Mars. 


On Board lime Tagged Command Execution 


The OBT tagged commands also belong to the class of time tagged 
commands. The onboard timer reference is from telemetry system, 
which is running continuously from system power on till end of the 
mission. The OBT commands are executed when the time running 
onboard matches with the OBT associated with the command. 

The uplinked commands are sorted according to the OBT as- 
sociated with them. The OBT logic compares the OBT of a com- 
mand having the least OBT stamp with the onboard running OBT. 
The OBT command is executed when the on board running OBT 
matches with the command OBT. 

The OBT software block diagram is shown in Figure 9. The up- 
linked commands are first validated by OBT validation logic. The 
validated commands are then processed by OBT sorting logic. OBT 
processing logic computes OBT difference between main and redun- 
dant TM OBTs to take care of telemetry auto-changeover. The com- 
puted difference is used to correct OBT after TM auto-changeover. 

The software also has the features like OBT command dele- 
tion and OBT stack reset. The OBT stack reset deletes all the OBT 
commands on board. 
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OBT commands are extremely 
useful when the spacecraft is not 
visible or in scenarios where direct 
commanding is not possible. For ex- 
ample, OBT commands are used for 
Liquid Apogee Motor (LAM) firing 
in case of visibility constraints. 


FAULT DETECTION, ISOLATION, 
AND RECONFIGURATION 


FDIR is important in this mission. 
The ground station will come to 


Up toN 

commands 
_ know any problem onboard the 
spacecraft after quite a large time 
as the distances involved are huge. 
Therefore, an effective mechanism 
is required to identify the faults, 
which can cause mission loss. As 


2"™' TT Command 
Execution 


we have seen, the general purpose 
functions in MTcP software can be 
programmed to take care of fail- 
ures in the other subsystems. But 
what will happen if the telecom- 
mand subsystem itself has a prob- 
lem is addressed in this section. 


Ielemetry Auto-Changeover 


Both main and redundant telemetry are available onboard. The 
MTcP works on selected telemetry; if the selected telemetry on- 
board goes into a problem state, then telemetry auto-changeover 
happens. For example, the parameters for TM auto-changeover 
are frame pulse failure, OBT errors, calibration voltage errors, TM 
frame cyclic redundancy check errors, etc. 

As both main and redundant telemetry are asynchronous, fea- 
tures like PATC, EBC, and OBT dependent on TM data are de- 
signed to function properly after TM auto-changeover. 

For example, in the case of OBT, generally the ground station 
selects one of the telemetry (let’s say TM1) and uplinks all the 
OBT commands with respect to the OBT in the selected telemetry. 
If the selected telemetry goes into problem, then telemetry auto- 
changeover happens. As the TM1 OBT reference is lost, the MTcP 
derives the TM1 OBT from TM2 OBT after TM auto-changeover 
as the uplinked commands have TM1 OBT tagged with them. 
Therefore, the OBT modules work even after the TM auto-change- 
over happens. 


MIcF Auto-Changeover 


The MTcP auto-changeover makes the TC subsystem robust. If 
there is a problem in the selected TC subsystem, then the auto- 
changeover happens to the non-selected/redundant subsystem and 
MTcP operation continues. So the system can withstand a TC sub- 
system failure until the ground station intervenes. 

The basic idea used for MTcP auto-changeover is as follows. 
The commands are uplinked to both the processors simultaneously 
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from the ground station so that their configuration and database 
remains synchronized if there is an uplink from the ground station. 
The changes done by the enabled/main processor in configuration 
onboard are transferred to a disabled/redundant processor so that 
their configuration remains the same after onboard actions. The 
functionalities running in a redundant processor monitor the same 
functionalities running in main processor and update their config- 
uration by looking at what is happening in main processor. This 
helps the functionalities running in a redundant processor to re- 
sume operation from the same point where main processor failed. 

For example, the OBT module running in main MTcP executes 
the commands when the OBT matures, but the OBT module run- 
ning in redundant processor deletes the OBT events whose time 
has matured instead of executing the commands. Therefore, both 
main and redundant OBT modules remain in synch. After MTcP 
auto-changeover happens, the OBT module running in redundant 
MTcP starts executing the commands and the OBT operation is as 
expected until the ground station intervenes. 

The functional diagram of TC autonomy is shown in Figure 10. 
Two kinds of failure detection are local and remote. For detecting 
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remote system failure, the heart beat signal is exchanged between 
the local and remote system. The heart beat signal tells about the 
health of that system to the other system. If there is a problem in 
the heart beat signal of the local system in a time window, then the 
remote system automatically takes over. 

In local system failure, the local hardware detects it and initi- 
ates the changeover. 


OTHER FEATURES 


Contigurable Command Blocks 


CCB is a block of commands. These commands don’t have any 
delay/time associated with them. The uplinked commands are vali- 
dated and stored onboard. The CCB is specified by a block number. 

The CCB is a set of commands which perform a definite opera- 
tion when executed. The CCB can be reused again and again. 

For example, CCBs are used for storing load shedding com- 
mands and also configuration commands, which can be triggered 
whenever required. 


eal-lime Commands 


Real-time commands have the highest priority among all the com- 
mands. These commands are executed immediately after validat- 
ing the uplinked command. 

For example, liquid engine burn commands are given in real 
time if the spacecraft is visible during the earth bound phase. 


Command/Data Transfer on 1353 Bus 


The TC system has a RT on the AOCE 1553B bus. All the 1553B 
commands/data are sent on this bus. The 1553B commands/data can 
be sent to AOCE BC and other RTs on the bus. The software supports 
real time, TT, OBT, and CCB commands through the 1553B bus. 

The software also transfers telemetry parameters to AOCE 
over the 1553B bus. All telemetry data are programmable. 

The MTcP software sends an executed telecommand history to 
a baseband data handling package on the 1553B bus. Therefore, 
the telecommand history is available in playback data. The execut- 
ed telecommand history is very useful for post-operation analysis. 

The main MTcP software also transfers data to redundant MTcP 
software in order to keep redundant MTcP software configuration the 
same as the main MTcP software. This configuration synchronizes 
redundant MTcP to take over when MTcP auto-changeover happens. 


Remote Programming 


The remote programming feature enables the MTcP software to 
accommodate new requirements. If any new software modules are 
required to meet the new requirements, then new software modules 
can be uplinked through ground commands. 

The remote program is provided with an enable/disable feature. 


Linking Features 


The real strength of the MTcP software is the ability to combine vari- 
ous MTcP features to perform an operation. It provides flexibility to 
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the mission team for planning com- 
plicated, autonomous operations. 

The linking feature also enables 
the reuse of already uplinked com- 
mands by triggering them again and 
again through EBCs, OBT, AOCE 
autonomy events, etc. 

For example, EBC triggering 
macro TT commands are used for 
Traveling Wave Tube Amplifier 
(TWTA) autonomy. The EBC detects 
the main TWTA failure and triggers 
macro TT to reconfigure the transmis- 
sion chain to use redundant TWTA. 


Diagnostic Features 


The processor status words re- 
ported in telemetry indicate the 
telecommand system health. As 
an interplanetary mission involves 
significant delays in getting telem- 
etry, it takes a lot of time to dump 
the uplinked data to ground sta- 
tions. Therefore, a checksum dump 
feature is provided for getting the 
checksum of all the database and 
commands stored onboard. 


TESTING AND EVALUATION 


Telemetry-telecommand (TMTC) package along with TC core 
card and distribution card is shown in Figure 11. 
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Figure 10. 


TC Autonomy functional diagram. 


> Sorting algorithm for OBT 
> Priority of execution 
> TM auto-changeover 


> MTcP auto-changeover 


Extensive unit level and system level testing [20], [21] was 


carried out for the MTcP software. The unit level and system level 
testing was carried out to verify the following: 


> Hardware software interface 


Pulse/level/data commands 


> Command decoding of all types of commands 


Boundary checks 


> Command validation logics 


> Checksum of data/command and actual data/command veri- 


fication stored onboard 
> Execution of commands 


> TC History to BDH 
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Uplinked command counter update 


Snap and Safe Mode Operation 


Decoding of proper sequence of uplinked commands 


Handling of improper sequence of uplinked commands 


In addition to the above testing, code walk through, design, and 
database verification was done. All the mission plans were tested 
in the setup shown in Figure 12 before actually sending them to the 
spacecraft. The setup consists of AOCE and TC packages equipped 
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Figure 11. 
TMTC package in MOM. 
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Figure 12. 
AOCE-TC setup for MOM. 


with a test station which is simulating telemetry and other inter- 
faces. 


RESULTS 


Time required for various activities in MTcP software develop- 
ment is shown in Figure 13. The entire software was developed in 
one and a half years. The exact path to Mars is known to very few 
people. Therefore, it was very difficult to finalize the requirements. 


Table 2. 
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Figure 13. 


Time required for MTcP software development. 


Apart from that, testing of auto-changeover under various mission 
scenarios was challenging. The fault injection was a difficult part 
of testing when most of the interfaces are asynchronous in nature. 

Table 2 gives the time line for the development of MTcP soft- 
ware in MOM. The MTcP software was developed with high prior- 
ity, as the launch window for launching the Mars Orbiter space- 
craft was in October-November 2013. 


Time Line for MTcP Software Development 


Development activities Date started Date completed Number 
(dd-mm-yyyy) (dd-mm-yyyy) of days 

MTcP Software requirements specification review 01-03-2012 05-04-2012 36 
MTcP software design 06-04-2012 02-09-2012 150 
MTcP software design review 03-09-2012 30-09-2012 28 
MTcP software coding 01-10-2012 15-11-2012 45 
MTcP software testing by designers 16-11-2012 10-12-2012 26 
Incremental design review for design changes 11-12-2012 15-12-2012 3} 
(based on testing by designers) 
Incremental testing for the design changes by 16-12-2012 01-01-2013 7 
designers 
Testing of software by quality assurance division 02-12-2012 12-03-2013 101 
Incremental design review for changes in design 06-03-2013 12-03-2013 7 
(based on OA observations) 
Incremental testing of software by quality assurance 13-03-2013 20-03-2013 8 
division 
Clearance for Programmable Read-Only Memory 21-03-2013 21-03-2013 1 
fusing by Subsystem Review Board 
MTcP software fused 22-03-2013 22-03-2013 1 
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LESSONS LEARNED 


MOM was challenging as the mission plans used to change de- 
pending on the current situation and inputs from the review com- 
mittee. There were few observations related to mission operations. 
The observations and the lessons learned are listed below. 

During one of the maneuvers, the LAM could not give the 
expected performance. The spacecraft could not achieve the ex- 
pected delta velocity due to under-performance of the LAM. After 
the analysis of the observation, it was found that the mission plan 
executed on that day was never tested in checkout. Therefore, it 
is better to avoid the operations that are never tested at ground 
checkout. 

The Mars Orbiter has many autonomy logics onboard. One of 
the logics, TWTA autonomy, changes the transmission chain auto- 
matically if the current transmission chain lands into a problem to 
ensure continuous telemetry transmission to ground station. When 
the logic was enabled, complete telemetry was lost as the TM 
channel programmed for detecting TWTA failure was wrong and 
the logic misfired. The TWTA autonomy logic could not change 
the transmission chain as the actions (commands) uplinked were 
not correct. The review committee advised to simulate the com- 
mands on the setup shown in Figure 12 before sending the com- 
mands to the spacecraft to avoid such mistakes. 

We also faced a few problems in thermo-vacuum and interface 
testing. The observations and lessons learned during the develop- 
ment phase are listed below. 

During the development, one of the Low Voltage Transistor- 
Transistor Logic Bus Hold (LVTH) [22] inputs was floating (in- 
puts that are not pulled up or down) and LVTH output was a part of 
bus arbitration logic. At room temperature, the system passed all of 
the tests. When the system was switched off and on at low tempera- 
ture (-18 degrees Celsius), the bus arbitration logic misbehaved; it 
was due to LVTH output which toggled its state at that tempera- 
ture. The processor could not initialize the software properly due 
to the failure of bus arbitration logic and in turn behaved like it was 
hanged. Therefore, it is better to avoid floating inputs. These kinds 
of observations are very difficult to analyze as it takes time to bring 
the thermo-vacuum chamber to -18 degrees Celsius if one wants to 
repeat the observation. 

Interface tests with other subsystems are very important. The 
MTcP transfers the executed commands history to BDH over 
1553B bus. During the transfer, BDH receives the valid number 
of words followed by the data (TC history) in a sub-address and it 
stores the TC history. The number of words is a 5-bit field. 1-31 
is represented as 1-31 and 32 is represented as 0. This representa- 
tion is same as the number of words field in the command word 
of 1553B protocol. The BDH software was expecting number of 
words to be 32 when the data has 32 valid words but the MTcP 
software was giving it as 0 as it was a 5-bit field. Therefore, when 
the valid number of words was 32, BDH was missing the data 
which we observed during interface test. 

There were no observations in the software performance after 
it was delivered for flight. All the functionalities worked per the 
defined requirements. The mission was perfect from the software 
point of view. 
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CONCLUSION 


The MTcP software design concepts presented in this article are 
successfully flown in MOM. The software is working well on- 


board the Mars Orbiter. The software design presented in this ar- 
ticle is simple, general purpose, and database driven. The design 
is robust and can withstand the main system failure by changing 
over to a redundant system automatically. The configurable fea- 
tures provided can be used to achieve autonomy in spacecraft. Due 
to programmability provided in the software, the same features can 
be used for different purposes in different phases of a mission. @ 
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